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The International Space Station (ISS) is in an operational configuration. To fully utilize 
the ISS and take advantage of the modern protocols and updated Ku-band access, the 
Huntsville Operations Support Center (HOSC) has designed an approach to extend the Ku- 
band forward link access for payload investigators to their on-orbit payloads. This 
dramatically increases the ground to ISS communications for those users. This access also 
enables the ISS flight controllers operating in the Payload Operations and Integration 
Center to have more direct control over the systems they are responsible for managing and 
operating. To extend the Ku-band forward link to the payload user community the 
development of a new command server is necessary. The HOSC subsystems were updated to 
process the Internet Protocol Encapsulated packets, enable users to use the service based on 
their approved services, and perform network address translation to insure that the packets 
are forwarded from the user to the correct payload repeating that process in reverse from 
ISS to the payload user. This paper presents the architecture, implementation, and lessons 
learned. This will include the integration of COTS hardware and software as well as how 
the device is incorporated into the operational mission of the ISS. Thus, this paper also 
discusses how this technology can be applicable to payload users of the ISS. 


I. Introduction 

T HE International Space Station (ISS) program is diligilently working to increase utilization of the resources this 
unique laboratory provides. Increasing the operation of experiments means making the Payload Developer’s 
(PDs) onboard equipment more accessable to the PD team. The recent onboard upgrades provided a 25Mbps 
forward link and a 300Mbps return link across the Ku-band communications equipment. Included in the same 
upgrade was the ability to use the Internet Protocol (IP) Encapsulation (CCSDS 133.1-B-2) standard. Personnel 
within the Huntsville Operations Support Center (HOSC), location of the ISS Payload Operations and Integration 
Center (POIC), at the Marshall Space Flight Center (MSFC), are taking advantage of the increased bandwidth 
available to extend the onboard ISS Payload Local Area Network (LAN) to the Payload teams. 

In defining the capability to extend the onboard LAN to the ground, it was important that the onboard payload 
system look and feel, to the PD team, as if they were onboard performing the experiment with a Payload LAN 
workstation. To make this possible the HOSC team developed the HOSC Payload Ethernet Gateway (HPEG). 
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HPEG bridges the ground users with their onboard payload 
using standard IP traffic. This paper presents the architecture, 
implementation, and lessons learned for the HPEG and the 
extension of the onboard LAN to ground users. 


II. Background 

The Obsolence Driven Architecture Redesign (ODAR) 
project completed spring of 2013, enables use of the 
Consultative Committee for Space Data Systems (CCSDS) IP 
Encapsulation standard for communications. ODAR 
enhancements also included increased forward (25Mbps) and 
return link (300Mbps) data rates. More bandwidth for 
communications enabled the POIC to extend the use of the 
Ku-forward link as a path to onboard payloads. 

Figure 1 outlines the end-to-end data flow for the Ku- 
forward link service. Starting with the payload the data flows 
forward in this manner: 

1. The Payload User initiates connection using 
standard applications through IP packets. 

2. HPEG service checks that the user is trying to send 
to an authorized destination and port. After 
verifying the user traffic, the HPEG will translate 
the address and forward for IP encapsulation and 
inclusion in the POIC forward link connection. 

3. The Mission Control Center in Houston (MCC-H) 
manages the aggregrated forward link. The 
Communications Data Processor (CDP) takes the 
POIC and MCC-H forward link traffic, insuring it 
does not exceed 25Mbps, and sends the data 
onward to the IS S. 

4. A POIC managed device, the enhanced 
Functionally Distributed Processor (eFDP), 

completes the formatting required to place the data on the Radio Frequency (RF) link. 

5. Once onboard the Ku Communications Unit pulls the IP packet back out and places it on the Payload 
LAN to be received by the payload. 

Communications on the Ku-retum link follow the same path onboard just in reverse. It is on the ground where it 
changes little. Payload return data is sent directly to the POIC. 

1 . The Payload sends the IP packets to the Ku Communications Unit. 

2. Once on the ground, the eFDP pulls out the payload traffic and forwards it to the POIC for processing. 

3. The Payload Data Services System (PDSS) server forwards the traffic related to the Ku-forward service to the 
HPEG. 

4. The HPEG then reverse translates the packets putting the payload user addresses back into the IP header and 
sends the packet to the user. 

III. Phase One System Modifications 

Changes to the onboard and ground systems are being implemented in a phased approach. Phase I allows the 
POIC flight team, also know as the Cadre, access to the use of IP protocols on the forward link. The Cadre are 
helping to verify the changes made to the system. This also provides them an opportunity to tweak operations 
procedures regarding the management of the service for users. Phase II enables remote payload users access to begin 
using the IP protocols. Phase II also introduces the use of the CCSDS File Delivery Protocol (CFDP) [CCSDS 
727.0-B-4] for initial use by the Cadre. In Phase III all capabilities are available for all users. The majority of 
systems changes were made and installed within the systems in the POIC. 

A. Packet Routing Example 




f 

eFDP 

/ 

\ 


MCC 

\ 

/ 

CDP 

/ 

\ 



Figure 1. Systems used to enable payload 
users to take advantage of the Ku-forward 
service. 
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Before exploring the changes to the rest of the system, it is important to introduce how the packets are managed 
to be correctly translated between the ground and onboard systems. Performing a Network Address Translation 
(NAT) is required to prepare the packets for routing on the destination LAN. The HOSC systems will provide the 
NAT for packets being placed on the Ku-forward link. For Ku-return link traffic a reverse NAT is performed to send 
the packets back to the user. NAT is not a new concept, but understanding how it is used will provide insight to 
later system change discussions. The NAT modifies the IP address fields in a IP packet so that the packet is now 
routable in the address space the packet is entering. If this translation did not occur, the onboard system would reject 
the packet when it 
was unpackaged 
from the IP 
Encapsulation 
frame in which it 
was transported. 

Figure 2 illustrates 
this process. 

Traffic accepted 
from the user has 
the HOSC 

provided Proxy IP 
address as the 
destination and the 
user IP address as 
the source. Within 
the HOSC system 
the source IP is 
translated to a 
recognized, 

routable onboard Figure 2. Shows the IP address translation required for Payload users IP traffic to be 
address and the route d correctly between onboard and ground systems. 

destination IP is set to the Payload destination actual address. The HOSC system will then work in reverse by taking 
the onboard addresses from the return packet and translating them back to the approptiate ground addresses and ship 
the packet to the payload user. 



B. POIC System Enhancements 

The Ku-forward system is composed of four different components. Two are, the Ku Session Service and Ku 
Proxy Service, running on the External Private (ePVT) servers and one is, the HPEG Service, running on an internal 
operational server. The fourth component is the different user session status interfaces provided. Figure 3 diagrams 
the components and the data flows between them. 

Each client session will have its own instance of a Ku Session Service and a Ku Proxy Service. (Note: The 
description of the Ku-forward system services in this section reflect the Phase I design. A later section describes the 
considerations and changes for Phase II of the installation.) 

1. Ku Session Service 

After the user authenticates with the HOSC systems, the user will begin the process of establishing a Ku-forward 
session by connecting to the Ku Session service. This service, through a defined interface outlined in the Payload to 
Generic User Interface Definition Document (PGUIDD), shows the user which destinations and protocols are 
available to that user. Once the destination for that session has been selected, the user will start the session and 
receive a Proxy IP address. This is the address to which the user will forward their IP traffic. In effect, this becomes 
the address of the server for that user. The proxy address is an address assigned from a pool of addresses that the 
HOSC systems will recognize and accept. Also assigned at this time is the HPEG onboard IP address. This IP 
address is the used to translate the HOSC system to an address recognized by the ISS onboard systems. It is also 
assigned dynamically from a preassigned pool of IP addresses made available to payloads. Figure 2 above shows the 
use of the proxy addresses. The session service also provides Ku-forward system information to the user. The 
information provided is Ku-band forward and return acquisition status, if the user is enabled to use Ku-forward 
service, and if the HPEG service is currently available. Users will take advantage of this status making sure the 
system is ready for operations with their payload. The ePVT box in Figure 3 shows where the service is running. 
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2. Ku Proxy Service 

The Ku Proxy service is paired with a session service. When the user starts a session, a proxy service is started to 
“listen” for the IP traffic. A raw socket will grab the packets sent from the user, perform the NAT, and send the 
traffic forward, multiplexing into the Ku-forward link. Before a packet is forwarded it is first checked to insure that 
the Ku-forward link is in Acquisition of Signal (AOS), the packet has a valid port (an exception is Internet Control 
Message Protocol (ICMP) Ping that has no port), and the user is enabled for Ku-forward communications. If any of 
these conditions is not met, the traffic will be dropped. For a port to be valid, it must be negotiated between the ISS 
Program and the payload user. As part of the discussion, the ports and protocols are reviewed by the ISS Program 
Information Technology (IT) Security Team for the onboard systems. Secure protocols are preferred for use and a 
list of recognized, acceptable secure protocols has been drafted. A subset of those have been listed as part of the 
standard service. An example of an included protocol is Secure Shell. The Ku Proxy service also logs all traffic, for 
a short amount of time, to be used for analysis if the system appears to be forwarding traffic incorrectly. 

3. HPEG Subsystem 

As a subsystem, the HPEG provides forward & return services and monitor & control capabilities. The monitor 
& control piece configures the HPEG system and reports status to the EHS System Monitor and Control (SMAC) 
software. It also receives commands from SMAC to insure that the HPEG subsystem is managed as part of the 
larger system. The forward service receives packets from the Ku Proxy service and properly formats them for the 
Johnson Space Center (JSC) CDP. HPEG forward service also throttles the maximum output rate to the POIC pre- 
negotiated portion of the Ku-forward maximum. This is done to ensure the POIC is a good steward of the resources 
allocated to payloads and payload systems. HPEG Subsystem Return Service receives traffic sent from ISS and then 
translates and ships the traffic to the Ku Proxy service. The HPEG Subsystem is seen in Figure 3 in the OPS labeled 
box. 
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4. Session Status User Interface 

The user interface (Figure 4), used to assist the Cadre as well as POIC ground system controllers, monitors 
consumer usage of the HPEG system. This information is provided per user. 

• AUID is the unique identifier for each user 

• Role is typically the payload ID and will define the privilages for payload users. 

• Destination indicates which location onboard the user is using. 

• EHS String is which collection of equipment that user is operating from and indicates to the controllers in 
which activity the user is participating. 

• The different IP fields help operators know which IP address to monitor if troubleshooting becomes 
necessary. 
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File View Options 
Active Sessions 

L«t Refresh: 0SU7>i9.35 GMT 



Figure 4. HPEG User Monitor and Control User Interface provides opertors insight into how the system 
is being used by each payload user. 

• Port will show which ports the user is using. 

• Session Start time reflects when the user activity started. 

• Last Update is changed each time the user performs a transaction. 

• Data rate, shown as Avg Kbps/ 3 sec) will be a very important field. This field will help the Payload Rack 
Officer (PRO) and Data Management Coordinator (DMC), two of the Cadre, insure that users are not 
exceeding their allocated data rate. In the event that a user is over running their allocation and impacting 
the traffic of other users, the PRO and DMC can coordinate to work with the user to insure the user can 
get back within their allocation. This screen will assist them finding which user to work with. The data 
rate calculation is averaged over three second intervals. 

• Forward and Return bytes reflects the bytes sent and received. 
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IV. Phase II System Modifications 

Phase II of the Ku-forward project adds an implementation of the CFDP application for payload users. This 
establishes when all users will have access to use Ku-forward for IP access to payloads. As with the Phase I 
changes, the first use of the CFDP will be by the Cadre. Having the Cadre use the service first provides time to use 
the service across the operational link verifing configurations and tuning is correct. 

Making the CFDP application usable for all the users required careful consideration. Configuring the CFDP 
engine requires knowing, in advance, all the possible end points with which it could be communicating. The 
dynamic allocation of IP addresses used in Phase I required the users to update the CFDP configuration file every 
time they started the service. Changes are due to the configuration file mapping each End Point ID (EID) with its 
associated IP address. This means having to use another service, such as Secure Shell or Remote Desktop, to modify 
the onboard CFDP configuration before starting the CFDP application. The same configuration change is also 
needed on the ground system. 

To simplify the use of the CFDP service it was decided to use a portion of the address space as reserved for 
CFDP users. Once a payload user is using CFDP, the POIC Customer Support Team (CST) will assign the user an 
onboard NAT address and a ground node ID. The user will use that IP address and node ID for the duration of his 
operations on ISS. It will also allow him to preconfigure the CFDP configuration file onboard. The only 
configuration remaining before starting the CFDP node is the enter the assigned proxy IP address. This is because 
the ground proxy IP address is still assigned dynamically for each session. The Ku Session service will also require 
the user to submit his assigned ground node at session start so that EHS can look up the reserved onboard IP 
address for that user. Other users not using the CFDP application will continue to work as they do in Phase I getting 
dynamic IPs for use onboard. 


V. Conclusion 

As the ISS continues to increase science utilization, it is important to take advantage of every resource available. 
Using the Ku-forward link enables payload teams the ability to more rapidly reconfigure experiments due to the 
increased bandwidth available. This empowers payload teams the ability to upload new configurations or provide 
new software loads more often. Direct access to the payload computers allows users better insight into the system 
operations allow better opportunities to troubleshoot their experiments when not performing as expected. Most 
importantly, the design of the system takes advantage of tools that utilize standard IP communications. Payload 
teams will be able to use off-the-shelf applications or standard socket libraries when developing software to take 
advantage of the Ku-forward link. The POIC continues to provide world class, novel solutions to our customers 
pushing the boundaries of system utilization to the edge of excellence. 

Appendix 


Acronym List 


AOS 

Acquisition of Signal 

AUID 

Application User Identifier 

CCP 

Central Command Processor 

CCSDS 

Consultative Committee for Space Data Systems 

CDP 

Communications Data Processor 

CFDP 

CCSDS File Delivery Protocol 

COTS 

Commercial Off The Shelf 

CPU 

Central Processing Unit 

CST 

Customer Support Team 

eFDP 

enhanced Functionally Distributed Processor 

EHS 

Enhanced HOSC System 

EID 

Endpoint Identifier 

ePVT 

external Private (LAN) 

ERIS 

EHS Remote Interface Server 

FWD 

Forward 
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GMT Greenwich Mean Time 

GTH Ground Transfer Header 

HOSC Huntsville Operations Support Center 

HPEG HOSC Payload Ethernet Gateway 

ICMP Internet Control Message Protocol 

ID Identifier 

IP Internet Protocol 

ISS International Space Station 

IT Information Technology 

JSC Johnson Space Center 

Ku Comm Unit Ku Communications Unit 


Ku-Band 

LAN 

LOS 

Mbps 

MCC-H 

MOP 

MSFC 

NAT 

ODAR 

PD 

PDSS 

PEHB 

PGUIDD 

POIC 

PVT 

RIC 

RF 

RTN 

TCP 

UDP 

WSC 


12-18 gigahertz range in the electromagnetic spectrum 

Local Area Network 

Loss of Signal 

Megabits per second 

Mission Control Center - Houston 

Mission, Operational Support Mode, and Project 

Marshall Space Flight Center 

Network Address Translation 

Obsolescence Driven Avionics Redesign 

Payload Developer 

Payload Data Services System 

Payload Ethernet Hub Bridge 

Payload to Generic User Interface Definition Document 
Payload Operations and Integration Center 
Private (LAN) 

Rack Interface Controller 
Radio Frequency 
Return 

Transmission Control Protocol 
User Datagram Protocol 
White Sands Complex 
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